home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000205_news@newsmaster….columbia.edu _Sat Oct 24 08:04:30 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id IAA22398
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 24 Oct 1998 08:04:30 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id IAA14316
  7.     for kermit.misc@watsun; Sat, 24 Oct 1998 08:04:29 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!newsfeed.berkeley.edu!xmission!news.cc.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Stop automatic resetting of terminal emulation?
  12. Message-ID: <$wFIGEPQCCWK@cc.usu.edu>
  13. Date: 23 Oct 98 21:06:06 MDT
  14. References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu> <zr359kB7TU8S@cc.usu.edu> <70ofhk$e9d$1@apakabar.cc.columbia.edu> <wegLF5YIzlTM@cc.usu.edu> <70q1jp$426$1@apakabar.cc.columbia.edu> <Pine.WNT.4.05.9810231439280.158-100000@neko.dental.washington.edu>
  15. Organization: Utah State University
  16. Lines: 62
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:9400
  18.  
  19. In article <Pine.WNT.4.05.9810231439280.158-100000@neko.dental.washington.edu>, Andrew J Pardoe <ap@u.washington.edu> writes:
  20. > I read with great interest the followups to my original problem. As the
  21. > followups were from three persons who are intimately involved with the
  22. > development of Kermit, let me throw back in a lowly enduser's perspective.
  23.     <omissions> 
  24. > However, I expect that whenever a piece of software offers an unexpected
  25. > or extraordinary feature that the software provide a method to turn off
  26. > that feature. When I searched through my manuals I was looking for a
  27. > command similar to "SET TERMINAL TYPE AUTONEGOTIATION OFF".
  28. > 
  29. > Hint. 
  30. > 
  31. > Thank you three gentlemen, anyway, for the without question the most
  32. > valuable software on the market today. It is a pleasure to use.
  33. ---------
  34.     To continue the thread just a little more. You are correct
  35. that a manual override or control of some kind would be a good idea.
  36. Implementing it may be a headscratcher for us keypushers, but we will see.
  37.     The problem again is the Telnet proper part of things is only a
  38. part of things. On most remote hosts it tries to tell, not listen but
  39. tell, the host what kind of terminal Telnet has negotiated. Tough luck
  40. if the host o/s never heard of that kind. On the client side the emulator
  41. may or may not be predetermined for a given terminal kind and won't work
  42. as expected if Telnet forces another kind.
  43.     Here we see Telnet lives in a world of its own, without essential
  44. feedback from the remote host o/s, nor from the client side, making its
  45. own treaties with the opposite Telnet. That is really stupid, no two ways
  46. about it. I do not appologize for being blunt here because the matter has
  47. ticked me off. To be fair I am also in the "vendor camp" and should have
  48. decoded all this years ago and done better then.
  49.     Telnet can negotiate aliases, a list of names which function
  50. identically, if we let it and write code to confine it to just that list.
  51. Telnet could have negotiated with the host software (on either end) to see
  52. if an offered name or maybe something totally new were acceptable, but it 
  53. does not. Some folks call this a loose cannon.
  54.     The real solution to the Telnet Terminal Type Option is to avoid
  55. it entirely. Telnet has not a clue on the matter. Instead, what "ought"
  56. to occur is let the terminal emulator and remote host o/s battle it out
  57. according to the terminal specs and whatever clever Plug&Play software
  58. resides on that remote host. The word ought is in quotes because some
  59. terminals support an ident query, some don't, some operating systems
  60. know how to ask about a variety of terminals, others don't. But many do
  61. and the most popular terminal kinds support an ident query; we ought to
  62. let them have a go at it (my VMS SET TERM/INQUIRE in the login script)
  63. and not keep Telnet TTYPE out of the act.
  64.     As Frank notes, and most experienced terminal emulation writers
  65. know, terminal names on today's operating systems are whimsical in
  66. spelling and not getting more disciplined. What might be known as "vt100"
  67. on one is unacceptable on another yet "VT100" is, as a simple example.
  68. Big sigh goes here. The situation is so muddled that algorithms (upper
  69. then lower case, etc) can help only to a degree. The most sophisticated
  70. chooser happens to be us, which is fine for the technically minded but
  71. a pain for others.
  72.     In this I have taken the human side of the puzzle, the exasperation
  73. experienced when the ground shifts with little to no notice, and have taken
  74. apart the technical mechanism (Telnet TTYPE Option) that causes it. Jeff
  75. is trying hard to make the mechanism work as well as possible, and if one
  76. chooses to play that game then he is doing his best. Two different approaches;
  77. neither is perfect. Upon reflection I think the game is silly, and there
  78. is the end-to-end approach that needs careful consideration. Even then
  79. we are not home free on the matter.
  80.     Joe D.